Lambda the Ultimate

This has got to be one of the sparsest language families. The classics are APL, APL2, A+, J, and K, which were developed in that order and have entangled histories. Nial is the dark horse. Glee is the newest. Nesl is a parallel array language. Then there's the programming language of Mathematica, which supports array operations.

Surely there are more?

I am very happy that I found GAP as it allowed me the opportunity to make a bad pun, I just had to try it when I read their description of how their web site had been organized.

I think the Grouping capabilities are pretty cool

In case any language collector around here still has a copy of Vyper (the Python interpreter written in Ocaml by John Skaller that used to live at http://vyper.sourceforge.net/) flying around: Don't delete it, it may be the last existing copy, since neiter the author nor sourceforge still have one.

(So much for the permanence of electronic reccords in the internet age...)

A Functional Semantics of Attribute Grammars

A definition of the semantics of attribute grammars is given,
using the lambda calculus. We show how this semantics allows us to prove
results about attribute grammars in a calculational style.

I didn't encounter attribute grammars since school, so it was refreshing to see them in this light.
I have to check yet, whether "abstract interpretation" used in this paper is related to the one from Oleg's paper.

Mozart Oz 1.3.1 final is released for all platforms.

Useful dicussion.

This site will automatically judge solutions to 121 problems in 21 languages.

Some interesting forum posts:

• C++ IO too slow
• Functional languages need special privileges

Since the "why are type systems interesting" thread is getting so long, I thought I'd start a new thread on this somewhat more specific issue.

I agree with Frank that software development is concerned with building artefacts (i.e, program, program modules, classes, libraries and what not) about which we can reason statically - which seems to me to be tantamount to saying that we must be able to understand the product we are building, not just be able to run it.

But let's back up a bit, and consider the problematic issue of gathring software requirements. This is one of the issues software engineering is struggling with. We aren't very good at establishing what the real customer requirements are, and even when we do, customers change their mind, or want more features in the next release. The iterative life cycle model isn't only (or even primarily) about fixing bugs. It's about evolving software per customer requirements.

Now let's assume a best case scenario, where we have consistent, even formal, requirements, and we design a software system that fulfills them. We can reason statically, with the aid of a static type system, and convince ourselves that the software does what's expected from it.

Now comes the next cycle, because users want changes and additional features ("show longer names on the tracker page", "enable keywords for comments" etc.) Some would argue that unless we are talking about making trivial changes, we should start form scratch and redesign the system. For various reasons, most of them obvious, this isn't what usually happens. We modify the exisiting sytem. Techniques like regression testing help us make sure we haven't caused too much damage.

Now, let's consider the question of whether the type system helps us with this sort of activity. Obviously, types give that same static guarantees for the changed program they give any type correct program. But can the type system do more? It's likely that some of the changes require chaneging the types we use in our system. Which type systems help us make such changes locally? Do types introduce unnecessary coupling to the sytem, making evolution harder? How about support for (sound) refinement, which would allow checking that changes are consistent with prior specification, while not propagating the the changes in the system in such a way that the impact of the change becomes unmanagable?

I think these sort of questions are worth considering. Thye may help us design better type systems, which would help solve a real need.

It's a milestone season for Eclipse. The Eclipse C/C++ Development Tools project has released CDT 2.0 final for Eclipse 3.0. They posted some nice CDT screenshots. There are screenshots for Eclipse, too.

I am having trouble wrapping my mind around the semantics of a pure functional programming language. In writing my current programming language I chose to treat the variable assignment expression:

x = 5

as the creation of a function named x.

x = 5 is semantically equivalent to:

x = fn () -> 5

Is this sort of 'variable assignment' considered to be an example of pure in the FP sense?

NOTE: if x (in the above example) were to be redefined, a new closure would be created with the associated value.

Sorry to ask such a trivial question, but I am having trouble finding semantic discussions concerning simple functional programming idioms.

Best regards,

M.J. Stahl